home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
osix400
/
osix400-minutes-90dec.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
13KB
|
354 lines
CURRENT_MEETING_REPORT_
Reported by Judy Messing/MITRE
OSI X.400 Minutes
Agenda
o Review of Draft Proposal for the use of the Internet DNS to
maintain RFC 987/RFC 1148 Address Mapping Tables
o X.400 Deployment Issues
o XNREN Discussion
o Announcement of new Working Group
o Operational Issues Discussion
- PRMD Organization
- Originator/Recipient Name Assignment
- Address Mapping
The meeting was convened by Robert Hagens, Working Group Chair.
The revised ``Draft Proposal for the Use of the Internet DNS to Maintain
RFC 987/RFC 1148 Address Mapping Tables'' (by Cole and Hagens) had been
circulated on many mailing lists prior to the meeting. This proposal
describes how the DNS could be used to store, retreive, and maintain the
mappings between RFC 822 domain names and X.400 O/R addresses. The
first order of business was the review of this draft proposal.
The following issues were discussed and resoved during the review:
1. Placement of TO-X400 and TO-822 resource records in the DNS tree
(Section 4). It was decided that both records should be placed
under the same DNS root. This should be done in both the
transitional and experimental phase of using the DNS for the
mapping tables. A suggestion was made to demonstrate this
placement more clearly in the document by a drawing of the domain
name hierarchy.
1
Steve Kille noted that placing the two records under the same root
provide a good facility for management of the mappings,
distribution of zones of the DNS, and for zone transfers. Placing
the records under the same root will result in a routing
performance loss because it requires lookups in two trees.
2. Determination of name for T0-X400 and T0-822 root (Section 4).
Hagens suggested the root name ORMAP.ORG. Steve Kille suggested a
new top level domain .TABLE. Then the root name would be
ORMAP.TABLE. The consensus was to request a new top level domain
.TABLE. If this request was not granted, the records should be
placed in ORMAP.ORG.
3. Structure of O/R Address in Domain Name Syntax (Section 4.1): Alf
Hansen proposed three alternative solutions:
o The syntax given in Appendix F of RFCs 987 and 1148.
o An algorithmic, more human readable, syntax replacing blank
attributes with a hyphen.
o An algorithmic, more human readable, syntax dropping blank
attributes.
Steve Kille remarked that the text syntax of RFCs 987 and 1148 are
now being used in other environments and strongly argued for
remaining aligned with that syntax. This syntax is also used in
the DNS standard. The consensus was to keep the syntax aligned
with the RFCs and to refer to RFC 1148 in the draft standard when
discussing the structure of the O/R addresses. The RARE printable
format will be used in text examples. In section 4.3, Step 2 of
the example, the wildcard count of 5 is a typo. This will be
changed to 6.
4. Error Recovery (Section 4.4): A discussion on the appropriate
action for the mapping algorithm based upon the DNS response code
resulted in a recommendation that this section be rewritten. The
new section on Error Recovery will reflect the way RFC 1148 handles
the case where a hit is not found in the mapping lookup table.
5. RFC 1148 Issues: The draft will reference RFC 1148 as the primary
address mapping document. RFC 987 will be referenced as a
secondary document.
6. Proposed Resource Records (Section 3): Hagens reported that the
types assigned to the new Resource Records defined in the document
are incorrect, but that real values would be assigned when the
draft is issued.
7. DNS Address Class (Section 6): Discussion was held on whether the
new Resource Records should be assigned to the Internet address
class, IN, or the ISO address class, ISO. Suggestions for the
assigned address class were to omit it, use a wildcard, add a new
class called ``mapping'', or use IN. The question was raised as to
2
whether the DNS implementations actually accepted an address class
other than IN. The decision was that IN would be acceptable, but
that Hagens would coordinate the address class assignment with Paul
Mockapetris.
8. Transition Phase (Section 5.3.2): The consensus was to remove this
section from the proposed draft and expand it into a separate
document. The current proposed draft and the new transition
document will reference each other.
9. Coordination and Administration (Section 5): The proposed draft
spoke of the master copy of the mapping database as the copy stored
in the DNS namespace. Steve Kille pointed out that there is a
global use of the mapping database and that it could be stored in
three forms: table form, DNS form, or X.500 form. At his
suggestion, the Working Group agreed that the proposed draft should
define a model on the global use of the mapping table and the
proposed transition document define the details of how the model
would be actualized.
The model is based on country. As a national issue, each country
decides whether its master copy of the mapping database is stored
in the DNS, a table, or an X.500 directory. If a country changes
from one master to another, it takes responsibility for moving from
its original master to its new master. Procedures to follow when a
country chooses to transition from one master to another must be
developed. Currently the RARE project is mastered in tables. Each
country maintains its own tables and the RARE Working Group
maintains the global mapping table. The United States will be
mastered in the DNS. At this time RARE is responsible for maintain
the mapping tables and the University of Wisconsin is responsible
for maintaining the DNS mapping records.
Discussion of XNREN PRMD
Alf Hansen gave a presentation on the XNREN, the Wisconsin Internet
X.400 pilot project PRMD. He made the following points:
o XNREN is experimental in nature.
o XNREN is a production-quality service-oriented PRMD.
o XNREN can be joined by any organization willing to operate a local
X.400 service and contribute to a better understanding of
operational issues.
3
The Wisconsin pilot project will offer ARGO X.400 code to non-commercial
private organizations. Currently there are two X.400 implementations in
XNREN: the University College London PP and Wisconsin ARGO X.400. The
pilot project is focusing on short term operational problems. NSF has
funded it for two years. Participating organizations must agree to the
following:
o Register their organizations and organizational units with the
ad-hoc XNREN Naming authority.
o Appoint a MHS site manager.
o Operate any RFC987 gateway according to agreed upon rules.
o Define X.400/RFC822 address mappings.
o Use commonly agreed upon mappings.
o Use locally defined mappings.
o Route traffic external to XNREN according to specified rules.
The XNREN pilot is a member of the International RD Service. It
provides connectivity to Internet mail and, under the leadership of the
Corporation for National Research Initiatives, plans to establish
contact with the national ADMDs with the goal of negotiating
interconnection agreements and experimental exchange of messages. The
XNREN PRMD is also interested in exchanging experiences and establishing
connectivity with other Internet PRMDs. XNREN will offer the following
services:
o Assist participants in the pilot in setting up their X.400 service.
o Produce informational material about service developments.
o Take an active role on X.400-related mailing lists.
o Allow testing of new software and procedures in XNREN.
o Incorporate X.400 technical innovations into experiments.
o Use the X.400 infrastructure to experiment.
Contact XNREN at:
postmaster@cs.wisc.edu
or
X400-project-team@cs.wisc.edu.
4
MERIT is operating an X.400 gateway to Internet for SprintMail. Mark
Knopper expressed interest in directly routing to XNREN.
New Working Group Announced
Rob Hagens announced the formation of the X.400 Operations Working
Group. Its goal is to insure interoperability between Internet PRMDs.
The first task of the group will be to draft a document that specifies
requirement/conventions of Internet PRMDs. Membership in this Working
Group will be limited to people with planning, deployment, and
operational responsibilities. The Working Group will address the
following issues:
o Basic Assumptions
o Connectivity
- Stack Choice
- Degree of interconnection
o Routing
- Necessity of well-known entry point
- Policy on transit traffic
- How to connect to ADMDs
o Collective representation of PRMDs
- Internationally
- Interacting with public carriers
o Forum for addressing mapping coordination
o 1984/1988 issues
o X.500 issues
The group discussed the necessity of forming a new Working Group. Steve
Kille wondered if the work was not within the scope of this Working
Group. Hagens said that the new Working Group was operational and
motivated toward concrete progress. He also said that if the current
Working Group had completed its agenda, it could be dissolved. The
first meeting of the X.400 Operations Working Group will be February
4-6, 1991 at NASA-Ames.
Operational Issues Discussion: PRMD Organization
Rob Hagens announced that a preliminary meeting of X.400 operational
people had been held on November 28 at the University of Wisconsin. The
following general assumptions had evolved for the Internet PRMDs:
5
o PRMDs can be directly connected to each other.
o PRMDs will not all be directly interconnected.
o PRMDs must have unique names in the US.
o A PRMD can be a naming authority for its organizations.
o A PRMD can be connected to 0 or more ADMDs.
o X.400 addresses should reflect organizational structure.
Address Mapping
Alf Hansen presented two proposed methods of address mapping when a user
of an X.400 system wants to send mail to a user of an RFC 822 system and
vice versa. One solution consists of mapping the elements of the
receiver's mail system address into elements of the sender mail system
address structure. The receiver address then looks like a valid address
of the sending mail system. In the second solution, the receiver's
address is left in the syntax of his mail system. For the X.400 to RFC
822 case, the recipients address is placed in a Domain Defined Attribute
and the Organization indicates the community the address refers to,
e.g., Internet or RFC822. In the RFC 822 to X.400 case, the recipient
address is placed in quotes in the left-hand side term of the domain
name; the community it placed on the right-hand side of the @ sign. The
group discussed the mapping issues, but no decision was made. Steve
Kille warned that if the chosen solution generates X.400 addresses than
messages with those addresses must be able to be delivered.
1988 X.400
Steve Kille suggested that the Working Group name 1988 X.400 as the
Internet supported standard. He pointed out that 1988 X.400 supported
directory, security, distribution lists and the message store. Kille
said one defect of 1988 X.400 was that it did not allow a 1984 X.400
user to address an arbitrary 1988 user. However, he said he had a
simple proposal that he intended to specify to correct this problem. In
the discussion, it was pointed out that GOSIP does not specify 1988
X.400 until GOSIP Version 3, which is two years away.
The final discussion of the meeting centered on determining if there was
any interest in writing a MIB for X.400 and X.500.
Attendees
David Brent brent@CDNnet.ca
Lida Carrier lida@apple.com
6
Robert Cooney cooney@wnyose.nardac-dc.navy.mil
Curtis Cox zk0001@nhis.navy.mil
Robert Hagens hagens@cs.wisc.edu
Alf Hansen Alf.Hansen@pilot.cs.wisc.edu
Steve Kille S.Kille@cs.ucl.ac.uk
Mark Knopper mak@merit.edu
Walter Lazear lazear@gateway.mitre.org
John Linn linn@zendia.enet.dec.com
Judy Messing messing@gateway.mitre.org
Tim Seaver tas@mcnc.org
Theresa Senn tcs@cray.com
Harvey Shapiro shapiro@wnyose.nardac-dc.navy.mil
Linda Winkler b32357@anlvm.ctd.anl.gov
Dan Wintringham danw@osc.edu
Russ Wright wright@lbl.gov
Peter Yee yee@ames.arc.nasa.gov
7